Method for improving bandwidth efficiency

ABSTRACT

In a method for dynamically managing a digital recording system&#39;s bandwidth requirements, accesses to the recording system&#39;s hard drive are prioritized according to a pre-defined policy which gives the first priority to the data streams being written to the disk, the second priority to the data streams being read from the disk, and the third priority to other accesses to the disk. The recording system&#39;s bandwidth efficiency may also be improved by optimizing allocation of the disk&#39;s storage space which is partitioned into lower bandwidth portions and higher bandwidth portions, where lower bandwidth data streams are stored in lower bandwidth portions and higher bandwidth data streams are stored in higher bandwidth portions. The inner portions of the disk are lower bandwidth portions and thus data streams are recorded from the inner diameter outwards to the outer diameter of the disk. A recorded data stream may be migrated from a higher bandwidth portion to a lower bandwidth portion.

TECHNICAL FIELD

[0001] The invention generally relates to a digital video recordingsystem, and more particularly to a method for bandwidth management in adigital video recorder.

BACKGROUND OF THE INVENTION

[0002] Existing digital video recorder (DVR) systems can only processtwo digital-video data streams at once. Typically, such systems handle“one in, one out”, that is, one data stream coming into the system froma digital tuner, or from an analog tuner with an MPEG encoder, and beingwritten to disk, and one data stream going out of the system, which isbeing read from a hard drive (HD) disk, fed through an MPEG decoder andNTSC encoder, and displayed on a TV set.

[0003] Due to the presence of multiple analog or digital tuners,multiple TV-set display capability, and streaming-media downloading viathe Internet, new generation DVRs are required to handle multipledigital data streams simultaneously. Some of these digital data streamsare time-critical. For example, a digital data stream coming into arecording system must be recorded accurately to a disk without loss orcorruption. Otherwise, a permanent glitch will appear any time therecorded program is replayed. Similarly, a digital data stream beingread from the disk and decoded for display on a TV must be delivered ina timely manner. Otherwise, the MPEG decoder will starve and a visibleglitch will appear on the screen.

[0004] The amount of data flowing through a single digital data streammay vary widely. Limited-quality video may require only 1-2 megabits persecond, while high-quality video full of rapid motion may requirebetween 10 and 15 megabits per second. New generation television systemsmay deliver data streams of 19 megabits per second or more. Moving thismuch data to and from a hard drive is a challenge.

[0005] Inexpensive high-value IDE HD disks today are capable ofsustained data transfer rates of anywhere from 6 to 18 megabytes persecond. Transfer rates vary according to the disk model, and also to thelocation on the disk to which the data is being transferred.

[0006] An HD disk's outer tracks have a higher linear data density (moresectors per track) than the inner tracks. Because an HD disk rotates ata constant rate, the outer tracks can thus accept and deliver more dataper second than the inner tracks. A typical HD disk may transfer data ata rate of 10 megabyte per second on the inner tracks, and a rate up to18 megabytes per second on the outer tracks.

[0007] Transfer rates show only one aspect of the disk's performance.They do not reflect the disk's need to seek between different areas ofthe disk. An operation typically requires 10-25 milliseconds per seek,depending on distance. In addition, they do not reflect the drive'soccasional need to read a data sector more than once due to errors onthe disk or to the effect of impact and vibration.

[0008] Finally, a DVR's HD disk is often used for more than simplystoring data streams of video content. The disk may also hold a filesystem or database containing information about upcoming programs,on-screen guide, and program scheduling. It may also hold executablesoftware used by the DVR. There may thus be many different clientsrequiring access to the disk. Some accesses such as digital video writeand read streams are critically time-sensitive. Some others are lesssensitive to delay. For example, slowing down access to executable codeor to a program-guide database may cause the DVR's user interface tobehave in a sluggish fashion, but does not cause errors or failure ofthe system. Some others are not at all time-critical and can be deferredfor a significant amount of time without anyone noticing. For example, abackground task looking for shows that might be of interest to a viewercan be deferred.

[0009] What is desired is a mechanism that would enable a digitalrecording system to dynamically mitigate competing bandwidthrequirements when multiple data streams are simultaneously handled.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010]FIG. 1 is a block diagram illustrating processes to determinewhether a DVR is running out of bandwidth; and

[0011]FIG. 2 is an exemplary graphical diagram showing a media stream isbeing recorded to the VCR's HD disk from the lower bandwidth portion(i.e. inner diameter) outwards to the high bandwidth portion (i.e. theouter diameter).

SUMMARY OF THE INVENTION

[0012] The invention provides a method for improving a digital recordingsystem's bandwidth efficiency by prioritizing data stream accesses tothe system's hard drive according to a pre-defined policy and byallocating the HD disk's space according to the characteristics of thedata streams being recorded. A policy module, together with a media datamanagement module, both of which are incorporated in the recordingsystem's master control program, implements the policy. The policyconsiderations include (1) data streams being written to the HD diskprioritized over data streams being read from the HD disk and (2) datastreams being read from the HD disk prioritized over other accesses tothe HD disk. The recording system's bandwidth efficiency may be improvedby recording lower bandwidth data streams in the lower bandwidthportions and recording higher bandwidth data streams in the higherbandwidth portions of the HD disk. A data stream is recorded from theinner diameter outwards to the outer diameter of the disk. A recordeddata stream may be migrated from a higher bandwidth portion to a lowerbandwidth portion.

DETAILED DESCRIPTION OF THE INVENTION

[0013] Referring to FIG. 1, illustrated is a system 100 for DVR'sbandwidth management, including a hard drive (HD) disk 160 which storesmedia data streams and other data, a master control program 110 whichcontrols the DVR's internal operations, a media data management module120 which determines whether the DVR is coming close to failing to meeta time deadline by calculating each data buffer's deadline time, apolicy module 130 which implements a prioritizing policy, and a diskdriver 170 which determines whether the DVR is coming close to failingto meet a time deadline by measuring the disk's total available time forall on-going data streams' input-output (I/O) requests over a specifictime period. The DVR handles multiple output media streams (being readfrom the hard drive) 140 and multiple input media streams 150 (beingwritten to the hard drive) simultaneously.

[0014] In order to balance and manage the competing demands on its HDdisk 160, the DVR must define a policy on receiving functions, specificbandwidth, and related conditions. It also needs to have mechanisms indetermining disk bandwidth availability, bandwidth allocation, andimplementation of the policy.

[0015] First policy consideration is the extreme time-sensitivity of thedata streams being recorded 150. Losing any portion of a data streambeing written to the disk will surely result in a gap in the recording.This gap cannot be repaired after the recording. Therefore, data streamsbeing written to the disk should have the top priority for diskbandwidth.

[0016] Second policy consideration is the comparative time-sensitivityof the data streams being read 140 from the hard drive. Failing to readany portion of a data stream from the HD disk in time will surely resultin a visible glitch on the screen, or an audible breakup in the audio.It is not so harmful as losing data being written, because a user couldalways rewind and view the content again and there could be a goodchance to retrieve the data properly the second time. Nevertheless, thisproblem should be avoided.

[0017] Third policy consideration is the less time sensitivity of someaccesses 180 to the HD disk. It is acceptable if a user interface (Ul)slows down when there is a high disk-bandwidth demand as long as it doesnot become annoyingly slow, or freeze up.

[0018] Corresponding to these policy considerations, the deferred,paused, or terminated accesses may be resumed as soon as the bandwidthshortage is mitigated. To optimize bandwidth efficiency, these accessesmay be resumed in a pre-defined order that is consistent with the policyconsiderations. For example, a data stream being written 150 prioritizesover a data stream being read 140, and a data stream being read 140prioritizes over other accesses 180 such as the tasks that may beperformed in the background. In a same category of data streams, apriority order of “nearest deadline first” can be adopted. For example,among several deferred data streams which were being read from the diskbefore they were deferred, the data stream with a nearest deadline isresumed first.

[0019] It is hard to have full control over the bandwidth requirementsof the data streams that are being handled. In some cases, e.g. ananalog tuner with a MPEG encoder, it is possible to predict thebandwidth requirements in advance quite accurately. In some other cases,e.g. digital data via satellite, the bandwidth requirements are quiteunpredictable because they may range from very low up to somewell-identified theoretical maximum and may vary through this entirerange from one moment to the next.

[0020] Very-high-bandwidth data streams are relatively rare. It ispossible to design a system with 100% guaranteed operation, i.e.pre-budgeting all streams for the theoretical-worst-case bandwidth.However, that solution would not be able to handle more than two streamsin today's conditions on hard drives and streams. Further, that solutionwould not be cost effective.

[0021] By implementing a proper bandwidth policy, a digital recordingsystem may work well with multiple data streams having a high, but lessthan maximum average bandwidth, and fall back gracefully if the actualbandwidth required exceeds what can be delivered. If the amount ofbandwidth required by the data streams being handled exceeds the totalavailable amount, the system should react promptly and automatically toprevent permanent loss of data being recorded.

[0022] In the short term, the system may free up disk bandwidth bystopping one or more of the data streams being read from the disk. Inpractice, this means deferring, pausing, or terminating the video streambeing played, and putting up a static display on the screen informingthe user that the system's bandwidth capacity has been exceeded.

[0023] In the longer term, the system may give the user a choice ofseveral ways to react to the overload. In responding to the overloadproblems, the user may want to do any of the following: (1) Wait aminute or so, with the video paused, and then try to resume theplayback. If the cause of the interruption was a brief burst ofhigh-bandwidth video being recorded, it is possible that there may nowbe enough disk bandwidth to handle all of the streams; (2) Cancel one ormore of the streams being recorded; (3) Jump to live. If the user waswatching one of the video streams being recorded, but was viewing thestream in a delayed mode, the user can choose to skip over the remainingdelayed portion of the program, and begin watching the program stream inreal time. Watching in real time does not require that the stream beread back from the disk. Rather, it can be viewed at the same time it isbeing written to the disk. This effectively reduces the number ofstreams competing for disk access; (4) Stop watching the currentprogram, and instead watch one which was recorded at an earlier time andwhich has a lower stream bandwidth and thus places less of a demand onthe disk. There may be other choices available to the user at somepoint. The system design shall be flexible enough to permit new actionsto be added.

[0024] Due to the dynamic nature of the data streams a DVR must handle,a static prediction of stream bandwidth is not useful. It is difficultto tell very far in advance whether or not the disk bandwidth is aboutto run out. This uncertainty is made worse by the extreme difficulty ofpredicting, with any real accuracy, the exact locations on the diskwhere a data stream may be stored. Thus it is extremely hard to know howrapidly the data is transferred to and from the disk itself.Furthermore, it is extremely hard to predict disk-related performanceproblems, such as read or write retries, disk defects, vibration andimpact, and the like.

[0025] Therefore, a dynamic stream bandwidth management must be adopted.Such management would be able to detect the fact that the system is justabout to exceed the HD disk's available bandwidth. It would also havethe system respond quickly enough to avoid losing data that is beingwritten to the disk. In effect, this management is based on anegative-feedback mechanism.

[0026] The information about actual disk-bandwidth usage can be gatheredand fed to one or more modules so as to implement the policy describedabove. These modules may be included in a DVR's internal code. Streamsbeing received and written to DVR's disk or played back after being readback from the disk pass through the media data management module 120,i.e. the Media Object Model (MOM) software module. This module isresponsible for buffer management and for caring and feeding the deviceswhich deliver and consume the data. MOM has substantial knowledge aboutthe internal format of the data streams such as PES triples and is alsoaware of the states of various buffers used to hold and manage the data.MOM contains code to estimate the deadline time for each buffer of datatransferred to or from the disk. In other words, MOM knows the time atwhich a buffer of data needs to have been written to disk so that thebuffer can be re-used to hold new data arriving from the input source,or to have been read from disk so that the data can be fed to the MPEGdecoder quickly enough to avoid a visible or audible glitch.

[0027] MOM can be enhanced to report this information to the policymodule 130 which implements the policy. In particular, if MOM determinesthat it has difficulty in reading or writing data in time to meet itsdeadlines, or in other words if it looks as if the system is comingclose to failing to meet MOM's deadlines, it can send a warning event tothe policy module 130 to report the fact. If a deadline actually ismissed, and if MOM determines that data has been lost or that a visibleglitch has occurred, MOM sends an urgent error alert to the policymodule 130 to report the fact.

[0028] The disk driver 170, which may be the kernel's disk driver, hasdetailed knowledge about the current state of each hard drive. A currentimplementation accepts deadline timing information along with each mediadata stream I/O request. It optimizes the order of accesses to the disk,in order to (1) guarantee that each deadlined I/O request is completedin advance of its deadline and (2) minimize the total amount of seektime required to perform the I/O requests. If the disk driver 170determines that it may be unable to satisfy the deadline requirements onall of its I/O requests, it reverts to an “emergency mode” and performsall deadlined requests in a “nearest deadline first” order.

[0029] To deal with bandwidth and deadline problems more effectively,the disk driver 170 can be enhanced in at least two ways. First, it canmeasure the total amount of disk bandwidth being used for media datastream I/O requests that have deadlines. Rather than trying to measurethis bandwidth in megabytes per second, it measures a percentage of thedrive's total available time over a relatively short period such as ½second or so. If the total media data stream I/O time is about to exceeda programmable threshold (e.g. 90%) for more than a specific amount oftime (e.g. 1 second), the disk driver 170 will send a warning signal tothe policy module 130.

[0030] Second, the disk driver 170 can implement a different internalpolicy in cases 5 where deadline violations appear to be inevitable.Rather than switching to a strict “earliest deadline first” policy, itmay implement a “writes are more important than reads” policy. It mayschedule any pending media write requests first in order to avoid lossof data. It may treat pending media read requests in either of twoways—“best efforts”, i.e., schedule them after the writes have beencompleted and hope that they meet their deadlines anyhow, or “earlyfailure”, i.e., cancel the requests as soon as a deadline violationappears inevitable so that MOM has more warning of the problem and canalert the policy module itself.

[0031] The policy module 130 is in charge of making decisions about whenit is necessary to stop playback of a data stream and offer the user achoice of alternative actions. The policy module can be also used inother ways to reduce the total I/O load on the recording system beforebandwidth is run out.

[0032] In particular, during the lasting period of a high media datastream I/O load, the policy module can decide to defer some of thesystem's background tasks which use an appreciable amount of disk I/Obandwidth. There are a number of obvious candidates for this sort ofdeferral. For example: the system's garbage collector and index-buildercan be held off or cancelled if they are already in progress; the daily“Phone the service provider to download updated showcases and/or programguide data” call can be deferred; and the suggestion prioritizer can beheld off or cancelled if it is already running. This kind of control canbe performed by the existing background-task supervisor in the MasterControl Program (MCP) 110 upon adopting a proper policy interface.

[0033] Referring to FIG. 2, illustrated is an exemplary graphic diagramfor a typical round disk which is partitioned into a lower bandwidthportion 220 and a higher bandwidth portion 210. The disk's ability totransfer data rapidly depends to a significant degree upon which portionof the disk is used. The inner portions of each platter have fewersectors per track than the outer portions, and thus require more time totransfer any given amount of data. Therefore, the recording system'sability to transfer high-bandwidth streams effectively can be improvedif it is possible to guarantee that the high-bandwidth streams arewritten primarily in the outer portions of the platter.

[0034] It is not always possible to know in advance how high thebandwidth of a given data stream will actually be. In other words, thedata about the bandwidth of a given data stream is sometimesunavailable. In many cases, however, an “after the fact” approach may beadopted to improve the system's bandwidth efficiency.

[0035] This approach includes the following steps:

[0036] 1. Divide the disk's media storage into a set of partitions to beused for different purposes. For example, the storage is divided intotwo media partitions: lower bandwidth portion 220 and higher bandwidthportion 210. The lower bandwidth portion 220 stores lower bandwidthstreams, starting from the inner diameter (ID) 230; and the higherbandwidth portion 210 stores the higher bandwidth streams, ending at theouter diameter (OD) 240. It is also needed to flag a given partition asbeing higher or lower bandwidth. This may be done via one of the sparebits in the partition table of a database. The bandwidth flag will bemigrated into a media file system (MFS)'s region data structures whenthe file system is initialized.

[0037] In one embodiment, a disk dedicates two partitions for the MFS.Within each partition, the MFS stores one or more regions for purposesthat are specific to the way that the MFS handles things. In onepartition, the MFS stores the “nodes” (i.e. the basic description ofeach file or directory) and the contents of the data files—this makes uptwo regions. In the other partition, the MFS stores a single regionwhich holds the video recordings. Associated with each region is a setof data structures, which are stored on disk (in the beginning of theregion area, usually) and are loaded into memory when the system isbooted. These data structures tell the MFS software how big the regionis (i.e. how many data sectors are in it), the size of the region'sallocation block size (e.g. the number of sectors it allocates each timespace is requested), and a set of “bitmaps” which identify theallocation blocks that are free (available) or in use (assigned to afile or recording). The bandwidth flag is a one-bit flag which says“This region is in the slower portion of the disk.” The flag is added tothe in-memory region data structure.

[0038] 2. Extend the MFS space-allocation API to accept an additionalparameter, indicating whether the data stream is known to be of lowbandwidth. If the low-bandwidth flag is set, space will be allocatedpreferentially from any available low-bandwidth partition 250, i.e. fromthe inner diameter outwards to the outer diameter. If the low-bandwidthflag is not set, space will be allocated preferentially fromhigh-bandwidth partitions, i.e. from the outer diameter inwards to theinner diameter. In either case, space will be allocated for the datastream if it is available in any partition because the system will notguarantee that an entire data stream will fall in either type ofpartition.

[0039] 3. Request low-bandwidth allocation when a stream of known lowbandwidth is being recorded to the disk. This may be done via MyWorld,or ele2pestriple or whatever is creating an MFS stream file, which setsa low-bandwidth flag. An MFS stream file is a way of storing MPEG-2audio and video data in a file on disk. Each stream file consists of aseries of “records”. A record consists of a fairly large number of diskdata sectors (typically 256 sectors per record, or 128k bytes). Eachrecord has some header information in its first sector which identifiesthe location, type, and size of each piece of audio or video data storedin the record. The MFS stream file is always written sequentially, forexample, from the first record to the last. During normal playback it isread sequentially. It may be read randomly, for example, skipping aroundforwards or backwards during fast-forward and rewind operations.

[0040] 4. When a data stream of unknown bandwidth is being recorded tothe disk, MyWorld, or the like, will not set a low-bandwidth flag.Consequently, the data stream is recorded on a high-bandwidth portion ofthe hard drive.

[0041] 5. Monitor the actual average or peak bandwidth required by thedata stream during the recording process. This may be performed by thesoftware for writing the data stream to the hard drive in terms ofactual data-arrival rate from the input medium or network, but wouldprobably be better performed by tracking the timestamps embedded in thedata stream itself.

[0042] 6. If, after a data stream of unknown bandwidth has beencompletely recorded, the recording software may check and determinewhether the recording's peak or average bandwidth is lower than apre-defined value. If yes, the recording software may choose to migratethe data stream to a lower-bandwidth portion of the disk. This can bedone by creating a new file for the data stream in a low-bandwidthportion, playing the contents of the data stream, and recording it intothe new file. As soon as the contents of the data stream have beencopied into the new file, the original file for the data stream isdeleted. This process can be performed in the background, with nodeadline times on the read and write requests. Therefore, it may use anyotherwise-unused disk bandwidth and does not interfere significantlywith deadlined 1/0 requests for other data streams being recorded orplayed.

[0043] This approach tends to result in the high-bandwidth, “greedy”data streams being located in those portions of the disk best able todeliver the data rapidly during playback. The average and/or peakbandwidth information for each recording may be stored in the system'sdatabase. This might enable the system to give a user an early warningif the user tries to play back a high-bandwidth recording when thereal-time bandwidth demands are already excessive.

[0044] Although the invention is described herein with reference to thepreferred embodiment, one skilled in the art will readily appreciatethat other applications may be substituted for those set forth hereinwithout departing from the spirit and scope of the present invention.

[0045] Accordingly, the invention should only be limited by the Claimsincluded below.

1. A method for dynamically managing bandwidth requirements for adigital recording system which stores data streams in a storage device,comprising the steps of: detecting a situation that said digitalrecording system is just about to run out of its available bandwidth;and implementing a policy to prioritize accesses to said storage deviceto avoid losing data from a data stream that is being written to orbeing read from said storage device.
 2. The method of claim 1, whereinsaid step of detecting a situation comprises the sub-steps of:determining, by a media data management module, whether said digitalrecording system is coming close to failing to meet a time deadline forwriting a data stream to said storage device or reading a data streamfrom said storage device; and, if yes, reporting this fact to a policymodule which implements said policy; wherein said media data managementmodule contains a code to measures said time deadline for each buffer ofdata transferred to or from said storage device.
 3. The method of claim2, further comprising the sub-step of: If a time deadline is actuallymissed, sending an urgent error alert to said policy module.
 4. Themethod of claim 1, wherein said step of detecting a situation comprisesthe sub-steps of: determining, by a disk driver, whether said digitalrecording system is coming close to failing to meet deadlinerequirements on all on-going data streams' input-output requests; and,if yes, reporting this fact to said policy module which implements saidpolicy.
 5. The method of claim 4, wherein said disk driver measures itstotal available time for all on-going data streams' input-outputrequests over a specific time period; and wherein if said totalavailable time exceeds a programmable threshold for more than saidspecific time period, then said driver determines that said digitalrecording system is coming close to failing to satisfy deadlinerequirements on all on-going data streams' input-output requests.
 6. Themethod of claim 4, wherein said disk driver is a kernel's disk driver.7. The method of claim 1, wherein said step of implementing a policycomprises a sub-step of: deferring, pausing, or terminating one or moreaccesses to said storage device in a priority order of: accesses otherthan data streams that are being written or read; data streams that arebeing read from said storage device; and data streams that are beingwritten to said storage device.
 8. The method of claim 7, furthercomprising the sub-step of: when said digital recording system'sbandwidth requirements are mitigated, resuming said deferred, paused, orterminated accesses in a priority order of: data streams that were beingwritten to said storage device before they were deferred, paused, orterminated; data streams that were being read from said storage devicebefore they were deferred, paused, or terminated; and accesses otherthan data streams that were being written or read before they weredeferred, paused or terminated.
 9. The method of claim 8, said datastreams that were being written to said storage device before they weredeferred, paused, or terminated are resumed in a nearest deadline firstorder.
 10. The method of claim 8, wherein said data streams that werebeing read from said storage device before they were deferred, paused,or terminated are resumed in a nearest deadline first order.
 11. Amethod for improving bandwidth efficiency of a digital recording systemwhich stores data streams in a storage device, said method comprisingthe steps of: partitioning said storage device's space into a set ofportions, some of which are used for storing lower bandwidth datastreams and some of which are used for storing higher bandwidth datastreams; indicating whether a data stream is known to be of lowbandwidth; requesting low-bandwidth allocation when a data stream knownto be of low bandwidth is being recorded; and monitoring an actualaverage or peak bandwidth required by said data stream being recorded;wherein each of said portions is associated with a set of datastructures which are stored on said storage device and are loaded intomemory when a media file system is initialized.
 12. The method of claim11, wherein the step of indicating whether a data stream is known to beof low bandwidth is performed by a parameter which is included in aspace-allocation API of said media file system.
 13. The method of claim11, further comprising the step of: flagging, by a flag, a given diskregion as a lower bandwidth portion or a higher bandwidth portion. 14.The method of claim 13, wherein said flag is incorporated into a datastructure associated with each specific portion of said storage device.15. The method of claim 13, wherein said flag is a one-bit flag whichshows that a specific area is in a lower bandwidth portion of saidstorage device.
 16. The method of claim 11, further comprising the stepof: if a low-bandwidth flag is set, allocating space preferentially fromany available low-bandwidth portion.
 17. The method of claim 16, whereinspace is allocated outwards from the inner diameter of said storagedevice.
 18. The method of claim 11, further comprising the step of: ifsaid low-bandwidth flag is not set, allocating space preferentially fromany available high-bandwidth portion.
 19. The method of claim 18,wherein space is allocated inwards from the outer diameter of saidstorage device.
 20. The method of claim 11, wherein said step ofmonitoring an actual or peak bandwidth is performed in terms ofactual-arrival rate from an input medium or a network.
 21. The method ofclaim 11, wherein said step of monitoring an actual or peak bandwidth isperformed by tracking timestamps which are embedded in said data stream.22. The method of claim 11, further comprising the steps of: checking arecorded unknown bandwidth data stream in a higher bandwidth portion todetermine whether its peak or average bandwidth is lower than apre-defined value; and, if yes, migrating said data stream to a lowerbandwidth portion.
 23. The method of claim 22, wherein said step ofmigrating comprises the sub-steps of: creating a new file in saidlow-bandwidth portion for said data stream; playing contents of saiddata stream and recording said contents into said new file; and deletingthe original file for said data stream once said contents are recordedinto said new file.
 24. The method of claim 11, wherein said step ofmigrating is performed in the background with no time deadlines on readand write requests.
 25. The method of claim 11, further comprising thestep of: caching average or peak bandwidth information for eachrecording in a database.